1. Field of the Invention
The present invention relates to techniques for generating a testbench for a representation of a device, so as to allow that representation of the device to be tested prior to the production of an actual device based on that representation.
2. Description of the Prior Art
When developing components for integration into a system, a number of test procedures are typically performed to ensure that the component will operate in the desired manner when integrated into the system.
The development of a hardware component (also referred to herein as a device) typically takes place in a number of stages. Firstly, the functional operation/behavior of the component is defined, for example using a Register Transfer Language (RTL). Two popular RTLs used are VHDL and Verilog. In addition, prior to performing such RTL coding, a behavioural model may be built using a UML (Universal Modelling Language) to validate at a transactional level that the design intent is correct.
Once an RTL representation of the hardware component has been developed, this is then synthesised into a sequence of hardware elements using any of a number of known synthesising tools. The result of the synthesis is a hardware design that can then be used to produce the actual hardware component, for example using appropriate fabrication of the component on silicon. It would clearly be very costly to perform test procedures on the component once it has actually been reduced to hardware, and instead rigorous testing of the RTL representation of the component is typically performed to ensure that the actual hardware generated from that RTL representation will operate correctly.
Such testing of the RTL representation typically involves the use of a testbench model providing a test environment for the RTL representation of the component, which is then run on a simulation tool to produce test results which can be analysed to determine whether the RTL representation of the component is operating as required.
The testbench can be formed in a variety of ways. For example, the testbench could be formed to provide a test environment for testing the RTL representation of the component in isolation, which enables direct control of the input stimuli to the RTL representation of the component. However, this requires a particular testbench to be produced for that component representation. Another approach is to combine that RTL representation of the component to be tested with RTL representations of other components that have already been tested, and with which the component to be tested will interact. Hence, in this approach, a portion of the overall system into which the component is intended to be placed is represented in RTL, and a testbench is then constructed based on that RTL representation of the system portion. This avoids the need to produce a particular testbench specifically for the component to be tested, but results in loss of direct control over the input stimuli to the RTL representation of the particular component to be tested.
It is possible to make a particular representation of a component configurable, for example in situations where the actual construction of the component may depend on the arrangement of other components within the system with which that component is intended to interact. One example of such a component which may be configurable is a bus interconnect block which defines the bus connections between various other devices within the system. The bus interconnect block will hence define the bus infrastructure that allows a number of master devices to access a number of slave devices. In such interconnect blocks, each master may be arranged to access a different sub-set of the slave devices, may be arranged to use different memory maps to those used by other master devices, and further each slave device may be arranged to use one of a number of different arbitration schemes. In this example, it will be appreciated that the actual layout of any particular bus interconnect block will depend on the specification of a number of different configurable parameters, such as the number of master devices in the system, the number of slave devices in the system, identification of the slave devices accessible by each master, etc.
Once these configurable parameters have been specified via some configuration data, it is then possible to generate a particular instantiation of the representation of the component. However, with many such instantiations possible, it has generally been considered impractical to try and provide a testbench which can test in isolation the configurable representation of the component to ensure that a working instantiation of that RTL representation can be created under all configuration options.
One option would be to perform detailed testing of a representative subset of configurations, and infer that every other configuration will perform similarly, but this is risky as it assumes that the configuration and generation always work exactly as planned.
Accordingly, instead, it is typically the case that when a particular instantiation of such a configurable RTL representation of a component is produced based on some configuration data, then that RTL representation is placed within an RTL representation of a portion of the system including RTL representations of other components with which it will interact. However, as mentioned earlier, the use of such an approach results in the loss of direct control over the input stimuli to the RTL representation of the component being tested, and hence is a less satisfactory test procedure.
Accordingly, it would be desirable to provide an improved technique for generating a testbench to be used in association with a representation of a device which is configurable.